Cumulative content of Working Group Meetings in 2025
Date: 22/04/2024
Participants: Natalie Muric
Model and note editor: Achilles Dougalis
Discussion
-
Announces vs. RefersTo #781 discussion
-
The reply to the question in the above Github discussion was discussed, and the proposed predicates depicted on the table below were reviewed. It was mentioned that predicate
epo:announcesRolefrom classepo-not:ContractModificationNoticeto classepo:AgentInRoleshould be changed toepo:refersToas it was discussed that a Modification Notice always refers to a pre-existing procedure with defined lots and roles, and does not introduce new roles.
-
-
The eQualification ORSD and eAwarding ORSDs were reviewed and discussed.
-
It was decided that the eQualification module should only represent the qualification sub-proccess used both by open and closed (mini competition) procedures.
-
As a result, eQualification, eAwarding and eEvaluation ORSDs were modified. Specifically:
-
eEvaluation: The qualification part after the evaluation process was removed from the ORSD.
-
eAwarding: The qualification part was replaced by a reference to the eQualification module.
-
eQualification: The description of the closed procedure was removed from eQualification, keeping only the qualification part. A detailed description of qualification for both closed and open procedures was written.
-
-
Action Points
-
Create a ticket: Predicate
epo:announcesRolefrom classepo-not:ContractModificationNoticeto classepo:AgentInRoleto be changed toepo:refersTo. -
To update the diagram of the offering party to include Candidate and any other roles currently missing from the diagram.
-
To continue fixes in the eQualification ORSD.
Working Group Meeting
Date: 15/04/2025
Participants: Natalie Muric, Pietro Palermo
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Agenda
-
eForms Requirements:
-
Discuss eOrdering requirements.
-
To address dct:issued and any other date/time concepts.
-
Present diagrams for OrderChange, OrderCancellation, OrderResponse, and OrderAgreement.
-
Discuss eFulfilment requirements
Discussion
-
The eOrdering requirements were discussed:
-
All the new diagrams were reviewed.
-
OrderCancellation CM diagram: To delete generalizations to OrderCancellation so it is harmonized with the OrderChange CM diagram.
-
dct:Issued attribute representing both date and time was discussed. Thw WG concluded that It is ok to just use dct:Issued in the Ontology to represent both date and time.
-
It was decided that the Implement Item property code for ePO #773 ticket can be moved to ePO 5.1.0.
-
-
eFulfilment requirements:
-
Model Fuel Consumption business group from the Despatch Advice data model #660:
-
It was decided that this ticket will be moved to ePO 5.1.
-
To investigate whether this is related to the EED concept from the eForms Annex.
-
-
-
The following github issues for ePO 6.0.0 were discussed.
-
epo-sub:ESPD should be a specialization of epo:QualificationResponse #699
-
It seems that there is a problem between PEPPOL pre-award data model terms and UBL. Perhaps the problem is that they are using an older UBL specification.
-
It was mentioned that qualification response is the UBL equivalent to the ESPD and not its specialization.
-
-
epo-acc:ESPDRequest should be a specialization of epo:TendererQualificationSubmission #700
-
It was mentioned that UBL’s Qualification Application Request is the UBL equivalent to the ESPDRequest.
-
-
Remove Predicate epo-sub:relatesToESPDRequest #701
-
The https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0007 regulation was discussed. After consulting the regulation the WG concluded that an ESPD does not necessarily require an ESPD Request. This is due to the fact that in many cases someone creating an ESPD will often use premade ESPD templates and will not need to create an ESPD Request.
-
-
epo:indefiniteDuration to be deprecated #587 was discussed.
-
it was agreed to remove epo:IndefiniteDuration while aligning with Time Ontology for ePO 5.0.0.
-
It was decided that there is a need to represent indefinite durations for standard forms for epo 5.2.0. Thus, a relevant ticket will be created.
-
-
-
Review related issues:
-
How is the relationship between epo:ReviewDecision and epo:ReviewRequest represented in eForms? #777
-
From a business point of view, the review decision should answer a review request and that’s why we are keeping the cardinality 1 for this release, and redescuss this in the context of alignment with eForms in a future release.
-
The ticket was moved to ePO 5.1.0.
-
-
-
It was decided that the following issues will be moved to 5.1.0:
-
It was decided that Problem with associations from Tender to Lot and LotGroup #683 will be moved to 6.0.0 as further discussions are needed as to whether a change is required in the Ontology.
-
Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726 : Although all the changes to the Ontology needed to accommodate the unmappable fields were implemented, they need to be reviewed.
-
Announces vs. RefersTo #781 discussion: The WG decided to create a spreadsheet that indicates what predicate should be used for each Notice – Entity pair.
Action Points
-
Update the Mappings to the eOrdering data models.
-
Update OrderCancellationConfirmation and OrderCancellationChange mappings.
-
Update the concepts related to the Time Ontology.
-
-
Create a Github Issue: The ESPD should become independent of the ESPD request. link it to #701 Remove Predicate epo-sub:relatesToESPDRequest
-
To follow up with the open Github issues on eCatalogue.
-
create a Github Issue: We need a way to represent indefinite durations for standard forms for 5.2.0.
-
Create a spreadsheet for Announces vs. RefersTo #781
-
Create a Github issue to model E1 (premarket consultation) notice.
-
To review Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726.
Working Group Meeting
Date: 08/04/2025
Participants: Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
OrderResponse field BT-ORL-5 Maximum backorder quantity was discussed:
-
Predicate epo-ord:hasBackOrderQuantity [0..1] was added from epo-ord:OrderResponseLine to epo:quantity.
-
-
OrderResponse field BT-ROL-2 Referenced Order line status code was discussed.
-
OrderCancelation
-
OrderCancelation became a postAwardDocument.
-
Predicate Linking epo-ord:OrderCancellation with Order was changed from epo:isSubmittedFor to epo-ord:isSubmittedForOrder.
-
It appears that we do not need the predicates pointed out below. This needs to be discussed further in a future WGM.
-
-
OrderChange
-
OrderChangeRejection and OrderChangeConfirmation became PostAwardDocuments.
-
To compare the implementations ofOrderChange and OrderResponse in a future WGM and decide what is the better one.
-
-
It was agreed that the OrderResponseConfirmation, OrderResponseRejection and OrderResponseSimple data-models can be modelled using epo-ord:OrderResponse.
-
For attribute epo-ord:hasDownloadURL, the following definition was added: "Location where the resource can be downloaded".
-
ePO tickets 743 and 611 were described, answered and closed.
Working Group Meeting
Date: 03/04/2025
Participants: Natalie Muric, Thomas Peterson, Kok Wim
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
Field
BT-OHI-6: The field represents a reference of the Order. We are going to delete the existingepo-ord:hasCustomerReferenceattribute, and turn it into a predicate connectingepo:PostAwardDocumenttoadms:Identifier.-
Definition: "A supplementary reference used to identify the Buyer’s internal process."
-
-
Field
BG-ADR: Question: Is this a Document, or a PostAwardDocument?-
Answer: It should be placed at the level of the
Document.
-
-
Field
BG-IPSP: What role should we use for that? We should create theepo-ord:Invoiceerole and not just use buyer as mentioned in https://docs.ted.europa.eu/epo-wgm/notes/2023-02-21-eord.html#_agenda.-
Class
epo-ord:Invoiceewas created as a subclass of the Acquiring Party.-
Definition: "The Role of an Agent who receives and processes the Invoices."
-
-
-
Predicate
epo:specifiesInvoiceewas added.
-
Predicates
epo:exposesInvoiceeChannel, andIndicatesInvoiceeContactPointfromepo:Buyerwere removed.
-
Field
BT-ODI-1-4-8-
At the level of
epo-ord:DeliveryInformation, attributeepo-ord:hasDeliveryEmailwas created.-
Definition: "The electronic address to which the products or services are to be delivered."
-
-
-
Field
BG-ODT: the solution provided in the ePO Github issue #623 was explained.-
Attribute
epo:GeneralDeliveryTermwas renamed toepo:hasGeneralDeliveryTerm -
locn:geographicNameshould be used forBT-ORDT-3instead of an identifier. -
Field
BT-ORDT-4was discussed.-
epo-ord:hasRequestedShippingPrioritywas removed fromepo-ord:DeliveryInformation, and was put underepo-ord:DeliveryAgreement
-
-
-
ePO Github issue #767 was discussed and marked as completed for the fields:
-
BT-OAI-6-4"Order allowance Exemption reason text" -
BT-OAI-6-5"Order allowance VAT exemption reason and specification code". -
BT-OCI-6-4"Order charge Exemption reason text" -
BT-OCI-6-5"Order charge VAT exemption reason and specification code".
-
-
Field
BT-OTO-5in Github Issue #696 was discussed, updated and closed. -
Field
BT-OL-6-5should only be used in the Order Change. Was removed. -
Field
BT-OL-10implemented as discussed in Github issue #766, and the solution provided was acknowledged by the Working Group. -
Field
BT-OL-11: It was decided to re-use attributeepo-ordhasAccountingCostat the level of the OrderLine. -
Field
BT-II-10-3: To create a GitHub issue to ask about the ItemNameCode. (Code for the item property according to a property code system) -
Fields:
BT-OAHI-10, BT-OCAREHI-10, BT-OCACOHI-10, etc. :It was agreed that we shall use attributeepo:hasAdditionalInformationat the level ofepo:Documentfor these fields. -
The diagrams for the
OrderChange,OrderCancellationandOrderAgreementwere presented:
Order Change diagram
Order Cancellation diagram
Order Agreement diagram.
-
Regarding Order Response:
-
Proposal to change
epo-ord:hasAcceptanceStatuspredicate fromOrderResponseInformationtoepo-ord:hasStatus -
Predicate
ImplementsContractfromOrderResponsewas deleted as it was not in use.
-
Action Points
-
To Reply to #695
-
Add a github issue for Item Property code.
Working Group Meeting
Date: 27/03/2025
Participants: Victorio Bentivogli, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
The Order Response, Change, Agreement and Cancelation data models were discussed and their respective ePO diagrams were presented.
-
The Order Cancelation diagram was developed, containing the new Classes
epo-ord:Cancellation,epo-ord:OrderCancellationRejectionandepo-ord:CancellationConfirmationas seen on the diagram below:
-
OrderAgreement: The Working Group struggled to understand this concept, and what is the difference with Order. After consulting PEPPOL’s OrderAgreement data model, the Working Group concluded that Order Agreement is an alternative Order.The diagram for the Order Agreement is displayed below:
-
Predicate
epo-ord:comprisesOrderLine, linkingepo-ord:Ordertoepo-ord:OrderLinebecameepo-ord:comprisesin order to be used by all subclasses ofepo-ord:Orderandepo-ord:OrderLine. -
epo-ord:hasStatuswas added at the level ofepo-ord:OrderLineso it can be referenced by theepo-ord:OrderChangeLineif needed. -
Classes
epo-ord:OrderChangeRejectionandepo-ord:OrderChangeConfirmationwere added as seen in the diagram below:
Working Group Meeting
Date: 25/03/2025
Participants: Victorio Bentivogli,Veit Jahns, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
Issue #744 was discussed: Attribute
epo:hasCalculationMethodwas added to the classepo-cat:EnvironmentalEmissionInformation.
-
Issue #730 was discussed:
-
We use the same Attribute for eOrdering and eCatalogue, both at the level of the OrderResponse, Catalogue Response, CatalogueResponseLine thus a more general definition is required.
-
Definition of
epo-ord:hasResponseDescriptionwas modified to: "Explanation of the response".
-
-
Issue #722 was discussed: The expert for the Catalogue concepts was pointed to the issue for review.
-
Issue #549 was discussed:
epo:hasProcurementScopeDividedIntoLotDefinition was updated to: “Defines Lot”. -
Issue #605 was discussed: it was agreed to remove attribute
epo:hasOJSTypeand change the datatype forepo:hasOJSIssueNumberfromxsd:integertordf:PlainLiteral -
Issue #662 was discussed: Since in eForms, the Subcontractors are referenced at the level of the Organization, as of ePO 5.0.0 the following implementation is adopted:
-
Removing
epo:foreseesSubcontractorand epo:specifiesSubcontractorspredicates betweenepo:Tenderandepo:Subcontractorand useorg:Organizationepo:foreseesSubcontractorepo:Subcontractor. -
Keeping
epo:Contractorepo:foreseesSubcontractorepo:Subcontractorandepo:Contractor epo:hasSubcontractor epo:Subcontractorsince they might be used in a future use-case.
-
-
Issue #610 was discussed: The name of the concept
epo:VehicleInformationwas changed toepo:CleanVehicleDirectiveInformationas depicted below:
-
Issue #623 was discussed:
-
The ePO team prefers not to have the
at-voc-new:document-typecode list on the level ofepo:Document, but a new Class for each of the concepts mentioned in the code-lists. -
It was argued that currently there is no need to change this as this code list is used to reference a number of additional documents.
-
Maybe that code list could be trimmed so we can only have relevant values.
-
There should be examples of that codelist.
-
Predicate
epo:documentUsedInPublicProcurementwas renamed toepo:hasDocumentType.
-
Action Points
-
Create a ticket to get all the values that are relevant to procurement that the
at-voc-new:document-typecode list contains. -
Fix Issue #623 and create another issue about Document status if needed.
Working Group Meeting
Date: 20/03/2025
Participants: Victorio Bentivogli
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussion
It was discussed that a new alignment with PEPPOL for eORdering effort has started, regarding Order change, Order response and Order Agreement.
Issue #641 was discussed
-
epo:hasCurrencycardinality was changed from[0..1]to1.
Issue #643 was discussed:
-
epo-cat:hasTaxSchemecardinality was changed from[0..1]to1.
Issue #575 was discussed:
-
Properties
epo-ful:hasOnCarriageShipmentStageandepo-ful:hasPreCarriageShipmentStagewere deleted.
-
Property
epo-ful:hasMainCarriageShipmentStagewas renamed toepo-ful:hasCarriageShipmentStage. -
Definition of
epo-ful:hasCarriageShipmentStagewas modified to: "The Shipment Stage for the last mile covered in a transport chain."
Issue #765 was discussed:
-
The main question is, if from a Business point of view, the Financing and Payer party should be at the level of
epo:LotResultor at the level of the Result Notice. -
They were put on the
epo:LotResultLevel because not all Lots mentioned in a Result Notice are always awarded. -
It was discussed that this issue could be treated in
ePO 5.1.0. -
Finally, it was agreed that
epo:BudgetProviderandepo:PaymentExecutorshould be mapped usingepo:AgentInRoleepo:conceptualisedByepo:Lot. It can also be used for aepo:PlannedProcurementPartandepo:Proceduresince they all are subclasses ofepo:ProcurementElement.
The following eForms fields were discussed in the context of their mappings to ePO:
-
Field
OPT-093-Review: An Identifier for a Review. It was not defined well, and no one has used this as of now (no data). -
Fields
OPA-36-Lot-Number, OPA-98-Lot-Number, OPA-36-Part-Number: These are Attributes of other fields currently not in use in eForms. They were designed to hold a number, but were discarded because eForms typically uses 2 fields to do this: One field has the measure and is coupled with another field that has the unit value.
Issue #549 was discussed:
-
Another option is to rename
epo:hasScopeDividedIntoLottoepo:aggregatesLot. -
The issue was left open to be discussed in a future WGM.
Issue #763 was reviewed.
-
There was a second request in the ticket:
-
"Also, the epo:definesTenderProcessor, epo:definesTenderReceiver, epo:definesProcurementProcedureInformationProvider and epo:definesOfflineAccessProvider and some new epo:definesXXX properties could be added to link all the above roles to epo:PlannedProcurementPart, without the need to instantiate the epo:AccessTerm and epo:SubmissionTerm classes."
-
The following answer was given to the above question: "Regarding the second request, since those roles are defined at the level of epo:AccessTerm and epo:SubmissionTerm in the case of a epo:Lot, we will keep the same implementation for a epo:PlannedProcurementPart."
-
Issue #764 was briefly discussed.
-
A a number of attributes and Predicates were moved from the level of
epo:ProcurementObjectandepo:Lot, to the level ofepo:ProcurementElement, in order to them usable byepo:PlannedProcurementPart. -
A more detailed explanation on the changes will be given as a comment of Issue #764.
Diagram showing the Ontology before the modification
Diagram showing the Ontology after the modification
Action Points
-
To discuss #765 with the eForms team.
-
The main question is, if from a Business point of view, the Financing and Payer party should be at the level of LotResult or at the level of the Result Notice:
-
Edit: It was agreed that the
epo:BudgetProviderand theepo:PaymentExecutorshould be mapped usingepo:AgentInRoleepo:conceptualisedByepo:Lot. It can also be used for aepo:PlannedProcurementPartandepo:Proceduresince they all are subclasses ofepo:ProcurementElement.
-
Working Group Meeting
Date: 18/03/2025
Participants: Victorio Bentivogli, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
Issue #757 was discussed
-
After checking eForms fields
BT-808andBT-807, predicateepo:specifiesReviewRequesterwas added on the level ofepo:ReviewDecision. -
Maybe in the future we can replace predicates
epo:specifiesReviewerandepo:specifiesReviewRequesterwith just anepo:specifiesRolepredicate.
Issue #756 was discussed.
-
Class
epo:ReviewInformationwas created. -
Predicate
epo:relatestoEFormsSectionIdentifierwas added with domainepo:ReviewInformationand rangeadms:Identifier. -
Attribute
epo:hasElementReferencewas removed fromepo:Documentand added toepo:ReviewInformation. -
Predicate
epo:resolvesReviewRequestwas renamed toepo:answersReviewRequest.
Issue #761 was discussed.
-
Indeed code list
at-voc:received-submission-typeseems to be redundant. -
All the values of the code list were analysed and it was made sure that for each value of the code list there is an attribute on class
epo:SubmissionStatisticalInformationthat represents it. -
The codelist
at-voc:received-submission-typewas removed.
Issue #762 was discussed.
-
epo:ProcedureSpecificTerm,epo:ContractSpecificTermandepo:LotSpecificTermclasses were deleted and all terms that were specialisations of these classes are now specializations ofepo:Term.
-
However, there are diagrams that show different points of view of specific terms. Eg, all the terms that were under
epo:ProcedureSpecificTermappear on a specific diagram as seen below. To discuss the business value for these diagrams in the future.
Terms related to Procedure
Terms related to Lot
Terms related to Contract
Working Group Meeting
Date: 11/03/2025
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
Issue #754 was discussed:
-
The problem with the ticket is that apparently the ND-ModificationSection is repeatable.
-
The Modification Justification Vocabulary was consulted.
-
A possible solution would be to extend the cardinality for the predicate (referring to Modified Notice Part Reference).
-
A use case was given: When the publications office changed name to OP, all the contracts had to be amended.
-
Based on that, each contract will have a single epo-not:ContractModificationNotice.
-
-
Predicate’s
epo:relatesToEFormSectionIdentifierlinkingepo-con:ContractModificationInformationtoadms:Identifier. cardinality was changed from[0..1]to[0..*].
-
Issue #758 was discussed:
-
A Contract always mentions Lots not LotGroups.
-
Are there actual notices with Groups of Lots? just a few but most were not done correctly.
-
It makes sense to have a Tender for a group of lots.
-
A predicate
epo:concernsLotGroupconnectingepo:ContractLotCompletionInformationwithepo:LotGroupwas added. -
Predicate
epo:describesLotCompletionwas renamedepo:concernsLot.
-
-
Issue #755 was discussed:
-
Both OPT-050-Lot and OPT-050-Part fields describe a status saying if the document is in an Official Language or not.
-
A solution to this would be to infer the value of this field by using the corresponding BT-708-Lot/Part and BT-737-Lot/Part fields.
-
Another problem is that since only a URL for procurement documents is provided, this URL may point to one or many procurement documents, resulting in many instances of access term.
-
Issue #732 was referenced. In that ticket it was mentioned that 708 and 737 are mutually exclusive, proving that indeed the OPT-050-Lot and OPT-050-Part values can be inferred by BT-708-Lot/Part and BT-737-Lot/Part fields. Although there is a mistake in the mappings for these fields as they go through a procurement document.
-
-
It was discussed whether that attribute
epo:isProcurementDocumentRestrictedof classepo:AccessTermis needed, because it can be inferred from the Ontology.-
It was decided that the attribute should be kept because it is mandatory for the standard forms.
-
It was also mentioned that there should not be a mapping for BT-14 in eForms since it can be inferred.
-
Working Group Meeting
Date: 11/03/2025
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Achilles Dougalis
Note editor: Grzegorz Kostkowski
Agenda
-
Reviewing and refining ORSD for eAwarding.
-
Questions about selected GitHub tickets. Discussions
Discussions
-
A question was raised regarding outstanding GitHub issues that were to be prepared by the mappings team. It was clarified that the tickets had not yet been prepared.
-
The activities description for eAwarding ORSD was discussed.
-
It was clarified that the Dynamic Purchase System must be completed before the Call for Tender.
-
It was confirmed that the Award Notification is related to a Dynamic Purchase System only if an individual is awarded a contract within the DPS.
-
It was determined that the Award Notification does not belong to the eAwarding module.
-
It was noted that there is no suitable location for the DPS within the current structure.
-
It was concluded that the scope of eEvaluation, as described in the ORSD, contained activities that do not belong to the eAwarding phase.
-
A decision was made to transfer three transactions to a newly established eQualification module, which was extracted from eAwarding. These transactions include Tenderer Qualification Request, Tenderer Qualification Receipt, and Tenderer Qualification Response.
-
-
The participants worked on the ORSD for eQualification module.
-
A new ORSD document was created for the eQualification module based on the one for eAwarding.
-
A precise definition of eQualification was formulated, capturing its scope, which pertains to DPS and requalification systems for works.
-
The Economic Operator role was added in addition to the roles previously defined for eAwarding.
-
The distinction between DPS and the Qualification System was clarified. It was stated that the DPS is entirely electronic as for now.
-
An additional distinction was made by explaining that the Qualification System is limited in time, whereas the DPS is not.
-
The definitions of QualificationApplicationRequest and QualificationApplicationResponse were reviewed in UBL documentation. It was noted that, in UBL, the response originates from the Economic Operator, whereas the request is sent by the Buyer.
-
An explanation was provided regarding the receipt, which is a document that contains only a yes or no response.
-
A reference was made to the Directive 24, which states that the Tender Qualification Submission for DPS is considered a request to participate and is submitted by a candidate.
-
A correspondence was established between source definitions in PEPPOL and existing ePO classes to identify any missing components. It was concluded that all necessary concepts had already been modelled but some require renaming.
-
-
It was determined that the Call for Competition corresponds to the CompetitionNotice and appears to already be covered.
-
The use cases and natural language statements that were initially created for eAwarding were transferred to the ORSD for eQualification.
-
The eAwarding use cases and natural language statements were revised.
-
It was noted that an award decision is rarely published on the Buyer’s website and is therefore not always accessible to the Tenderer.
-
It was clarified that the Award Decision may be linked to Award Outcomes, but not to tenders.
-
It was clarified that the Award Decision is not linked to a Lot.
-
The statement regarding the standstill period was refined. It was originally stated that the standstill period lasts for 30 days, but it was adjusted to specify that the period lasts for one month.
-
It was communicated that the organization of tickets on the ePO 5.0.0 issues board had been modified, and some tickets had been categorized as low-hanging fruit.
-
Selected GitHub tickets were reviewed. Out of nine planned tasks, three were discussed, and a decision was reached for one of them.
-
-
-
The possibility of releasing a patch was discussed regarding ticket #476. It was noted that the ticket does not clearly specify the nature of the bug. A question was raised regarding why the ticket is included in the scope of version 5.0.0.
-
Ticket #711 was reviewed. It was noted that a decision had already been made during a past meeting.
-
Ticket #374 was analysed. It was stated that the issue is not of concern if it is harmless. Nonetheless, a suggestion was made to remove the attributes mentioned in the ticket if they do not serve a specific use case. A decision was made to remove these attributes, and the decision was documented in the ticket.
Working Group Meeting
Date: 06/03/2025
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric, Pietro Palermo, Cristian Vasquez
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
“aux: mapping” label
-
#738 ticket was discussed :
-
BT-684-Lot IPI regulation was discussed. That indicator is forbidden for contract notices. They are only part for result notices, 29, 30 and 32-37. It was discussed that the indicator is not needed in ePO and the ticket was closed.
-
-
#745 ticket was discussed, and closed.
-
#712 ticket (unpublished fields) was discussed.
-
Some changes will be done by eForms SDK 1.15 regarding concepts.
-
They will do a new section of unpublished fields at the beginning of the xml.
-
In ePO we should extend the range of ePO maskable concepts.
-
-
For now (regarding SDK 1.8-1.13), the current solution is satisfactory.
-
-
#529 ticket was discussed (Time Ontology, epo:Period)
-
It was discussed that the ePO will adopt the Time Ontology as seen in the diagram below
-
-
-
TC440 Order data model latest updates were discussed Specifically it was asked that the ePO team:
-
Goes through the old Order data model and make sure that ePO covers it.
-
Fills in Order change Order response, Order agreement tabs.
-
There will be a different annex for ePO concept mappings. There will be a deadline by April.
-
-
During the discussion, it was mentioned that the Quotation concept is not different from a Catalogue.
Action Points
-
Account for all open issues with milestone ePO 5.0.0
-
Also suggest which open issues should go to epo 5.1.0 or 6.0.0.
-
Working Group Meeting
Date: 04/03/2025
Participants: Victorio Bentivogli, Veit Jahns, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
Further Clarifications for modeling a Pre-award Catalogue were given:
-
epo-cat:ProductSpecification was moved on the level of epo:Document and not epo-cat:PostAwardDocument.
-
At-voc-new:document-type was moved to the level of epo:Document.
-
Predicate epo-cat:hasDocumentType was renamed as epo:documentUsedInPublicProcurement
-
Attribute epo-cat:hasHazardousClass of class epo-cat:AbstractItem was removed
-
Predicate Epo-cat:hasHazardousClassID was created with domain epo-cat:AbstractItem and range adms:Identifier.
-
Attribute epo-cat:hasClassificationCode [0..1] was added at the epo-cat:ItemProperty.
-
Predicate adms:identifier with domain epo-cat:ItemProperty and range adms:Identifier was added.
-
As seen in the diagram below,Class Epo:ProcurementDocumentsProvisionLine was created.
-
PreAwardCatalogueRequestLine was added.
Action Points
-
Create Github issues for 5.0.0:
-
For Item Seller Extended Identifier.
-
Item property unit of measure, unit of range and maximum value.
-
For lines 234-237 (range, dimension) link this to https://github.com/OP-TED/ePO/issues/661
-
-
Close 623 github issue.
-
to Investigate the reasoning behind the use of “ procurement documents provision” naming and not ”call for tenders”.
Working Group Meeting
Date: 27/02/2025
Participants: Victorio Bentivogli, Pietro, Dragos Stoica,
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
During the meeting, the 'request for offer' diagram was discussed, and expanded.
-
Regarding the above diagram, the following notes were made:
-
Should we use pre-award Catalogue, post-award Catalogue or both?
-
In UBL, we have a reference to the Contract.
-
Proposal to move the attribute epo:hasAdditionalInformation of Class epo-req:RequestForOffer at the level of the epo:Document since there are other documents that might re-use it; it also exists at the level of the epo:Notice, which is a type of epo:Document.
-
in UBL , RequestForQuotation, the DestinationCountry is at the level of the document.
-
can the delivery information be at the line level as well?
-
-
Regarding GitHub issue fixing for “aux: mapping” label:
-
The Review ticket in https://github.com/OP-TED/ted-rdf-mapping-eforms/issues/84 was discussed.
-
Working Group Meeting
Date: 25/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica,
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
-
During the meeting, the eRequest ORSD was developed.
-
The introduction was expanded: “In the procurement domain, eRequest represents a document created by the Buyer to request an offer for goods and services from a Contractor within a Framework Agreement and direct awards for procurements below threshold (small scale procurement).”
-
The Roles Involved were expanded:
-
Buyer
-
Contractor
-
Offer Issuer
-
-
The Activity description was expanded:
-
The Buyer sends a Request for Offer to the Contractor.
-
The Contractor receives the Request for Offer and analyses it.
-
The Offer Issuer issues and sends the Offer to the Buyer.
-
The Buyer receives the Offer and analyses it.
-
If the Offer is accepted, the Buyer writes the Contract/Order based on the Offer.
-
If the Offer is not accepted, the Buyer may ask for modifications of the Request for Offer and re-start the process.
-
-
-
-
During the meeting, the eAwarding ORSD was further developed.
-
The DPS was further explained by sharing this document.
-
The Description was divided into two segments: Awarding Notification and Dynamic Purchase System.
-
For the Dynamic Purchase System the following description was added: “Dynamic Purchase System
-
The Buyer creates a Call For Competition.
-
The Unique Responsible of the Procurement *ensures *the evidence for the Participation Conditions and the Qualification Criteria are fulfilled by Candidates proposed for Qualification.
-
If the evidence is good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is accepted on the Candidate List.
-
If the evidence is not good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is not accepted on the Candidate List. “
-
A Call for Tender is created.
-
-
-
The Award Decision Notification diagram for the eAwarding module was presented and expanded. By the end of the WGM the diagram looked like this:
-
In the above diagram epo-awa:AwardDecisionNotification was defined.
-
AwardDecision Attribute hasAdditionalNonAwardJustification became hasAwardJustification.
-
Definition was updated as follows: "Description of the reason behind an award or non-award of a given Tender.Additional information: This is generally used when the non award justification code is set to "Other" and when the Lot is awarded. It may highlight the justification of the non-award of a Tender with regard to awarded Tenders."
-
Action Points
-
Fill in the rest of the eRequest ORSD Fill in the rest of the eAwarding ORSD
-
Create a github issue: To look and check for the semantic wording for all the classes in the Ontology that have a composite naming.
-
Model the Qualification Resolution found here: https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-TendererQualificationResponse-2.4.html#Table-QualificationResolution.Details
-
Model the TenderReceipt: Model the https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-TenderReceipt-2.4.html
Working Group Meeting
Date: 20/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica.
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Agenda
-
ESPD
-
eRequest
-
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
Discussions
The ESPD #413 ticket was discussed again:
-
It was mentioned that information such as the one mentioned in the ticket should be Additional Information.
-
It was decided this should not be of class cccev:Evidence, as it is currently modeled and it should be modeled differently.
-
There is a need for a superclass other than Evidence.
Information on the eRequest concept was given:
-
It is a request for an offer in a Framework agreement, and its response. It is also related with mini-competition.
#691 was discussed:
Concerning the review diagram:
-
Class epo:ReviewObject was removed.
-
Attribute epo:hasNumberOfReviewRequests of class epo:ReviewRequest was removed.
-
Attribute epo:hasRequestDate of class epo:ReviewRequest was removed.
-
Attribute epo:hasDecisionDate of class epo:ReviewDecision was removed.
-
Class epo:ReviewRequest became a specialization of epo:Document.
-
Class epo:ReviewDecision became a specialization of epo:Document.
-
Predicate epo:specifiesReviewRequester [0..1] with domain epo:ReviewRequest and range epo:ReviewRequester was added.
-
Predicate epo:specifiesReviewer [0..1] with domain epo:ReviewDecision and range epo:Reviewer was added.
-
Attribute epo:hasElementReference xsd:anyURI [0..*] was added to class epo:Document.
-
Attribute epo:hasNumberOfReviewRequests xsd:integer [1] was added to class epo:ReviewRequestSummary.
Concerning the completion notice relations diagram:
-
Predicate epo:announcesReviewObject [0..*] with domain epo-not:CompletionNotice and range epo:ReviewObject was removed.
-
Predicate epo:refersToReviewRequest [0..*] with domain epo-not:CompletionNotice and range epo:ReviewRequest was added.
Concerning the result notice relations diagram:
-
Predicate epo:announcesReviewObject [0..*] with domain epo-not:ResultNotice and range epo:ReviewObject was removed.
-
Predicate epo:announcesReviewRequest [0..*] with domain epo-not:ResultNotice and range epo:ReviewRequest was added.
Action Points
-
Create github issue for TED mappings repository informing for the changes done in this WGM regarding the review concepts.
Working Group Meeting
Date: 18/02/2025
Participants: Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
The eAwarding Ontology Requirements Specification Document (ORSD) was further developed. Specifically:
The following Roles are involved in eAwarding:
-
Unique Responsible of the Procurement – played by a Person; it is part of the Buyer’s Organization (the head of the Organisation; the person that has the final decision)
-
Buyer
-
Tenderer
-
Winner
-
Candidate
The Award Decision is based on the Evaluation report. The Unique Responsible for the Procurement either accepts the findings of the Evaluation Report, or takes another decision (in case the winner does not fulfill all the criteria for the award of the contract).
The Activity description section was written as follows:
-
The Award Decision is written by the Unique Responsible of the Procurement.
-
The Unique Responsible of the Procurement *ensures *the evidences for the Participation Conditions and the Qualification Criteria are fulfilled by Tenderers proposed for an Award.
-
If the evidences are good, the Award Decision is signed by the Unique Responsible of the Procurement.
-
If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer:
-
If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.
-
If the clarification confirms that the evidence is not good, the evidences of another Tenderer(s) are checked until we reach the required number of Winners
-
-
-
The Tenderers are notified about the result through one of the following:
-
Award Decision is* published* on the Buyer’s website
-
Award Notification is *sent *to the Tenderers
-
-
A standstill period (while the contract cannot be signed) of one month starts from the notification to allow other Tenderers to request Review.
-
At the end of the standstill period the Contract can be signed.
-
No later than 30 days after the conclusion of a Contract, a Result Notice must be published.
The following Use cases were added:
| Use case | Description | Actors | Flow |
|---|---|---|---|
The Award Decision is written |
The Award Decision is* written *by the Unique Responsible of the Procurement. |
Unique Responsible of the Procurement |
The Unique Responsible of the Procurement writes the Award Decision based on the Evaluation Report. |
Participation Conditions and the Qualification Criteria are checked |
The Participation Conditions and the Qualification Criteria are assessed. |
Unique Responsible of the Procurement |
The Unique Responsible of the Procurement ensures the Participation Conditions and the Qualification Criteria are fulfilled by checking the evidences referenced/written in the ESPD. |
Clarifications from the non-compliant Tenderer are required |
If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer. |
Unique Responsible of the Procurement, |
If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement. |
The Award Decision is signed |
The Award Decision is* signed* by the Unique Responsible of the Procurement. |
The Unique Responsible of the Procurement signs the Award Decision. |
|
The Tenderers are notified about the result of the procurement. |
The Award Decision is published on the Buyer’s website OR an Award Notification is sent to the Tenderers. |
Buyer, Tenderer |
The Tenderers are notified about the result through one of the following: |
It was noted that the Qualification Response should be in another module.
Working Group Meeting
Date: 13/02/2025
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
ResponseStatus codelist was put at the level of AbstractContainer as seen on the diagram below:
-
Further Questions regarding the fields of the Receipt advice data model were answered.
There was a further discussion with the ESPD team regarding ticket https://github.com/OP-TED/ESPD-EDM/issues/413:
-
Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be
epo:canProvideEvidenceAlso the attribute coversAllSelectionCriteria should be at the level of the evidence.
Action Points
-
Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.
-
Add a Github Issue about renaming that highlighted property mentioned above.
Working Group Meeting
Date: 11/02/2025
Participants: Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
A new definition for the epo-sub:ESPD was given according to the diagram below:
Issue #734 was updated accordingly, and epo-sub:ESPD and ePO-acc:ESPDRequest: were updated accordingly.
The WG started discussing about the ORSD for the eAwarding module.
ESPD-EDM https://github.com/OP-TED/ESPD-EDM/issues/423 and https://github.com/OP-TED/ESPD-EDM/issues/413 issues were discussed:
-
#423:
-
eForms and UBL are not aligned, ESPD is aligned with UBL.
-
A qualifying party has a codelist that describes the role. So ESPD is covered by this. 423 can thus be closed.
-
-
#413
-
It was discussed that although the specific field mentioned in issue #413 covers multiple lists or equivalent certificates, in the ePO there are no Lists.
-
It was mentioned that the information conveyed by that specific field is not used as an evidence for any criterion and that it should be modelled as additional information and not evidence.
-
Working Group Meeting
Date:30/01/2025
Participants: Peter Borresen, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Alignment with PEPPOL for eFulfilment #569.
Discussion
-
Alignment with PEPPOL for eFulfilment #569.
-
Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.
-
Action Points
-
Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
The epo:associatedWith rather than a direct link to an epo:Document.
Also add a link from the lines to a document.
-
Create a ticket This at-voc-new:RespoonseStatus should be renamed and aligned with https://docs.peppol.eu/logistics/2024-Q1/codelist/UNCL4343_T128/
Working Group Meeting
Date: 28/01/2025
Participants: Victorio Bentivogli, Paul Donohoe, Ioannis Fountoukidis, Yves Jordan, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
Discussions
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
During the meeting, definitions for the following BTs that appearon the Annex of Regulation 2023/2884:
-
BT-776 did not have any impact on the Ontology.
-
BT-810
-
Is the indicator attribute epo:isCompliantToEnergyEfficiencyDirective needed? It was decided that this indicator will not be modelled since if it is true we will have an instance of epo:EnergyEfficiencyInformation.
-
-
BT-811
-
Two code lists are needed:
-
Energy-efficiency-Item (already in ePO)
-
Energy-efficiency-Basis (not in ePO)
-
-
As a result, at-voc:energy-efficiency-basis was created, and linked to epo:EnergyEfficiencyInformation. (see diagram below).
-
-
Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.
-
813 and 814 are paired.
-
BT-814 :
-
It was discussed that this will be implemented with the SDK implementation., not with the Regulation 2023/2884.
-
Two predicates connecting epo:EnergyEfficiencyInformation to epo:Quantity will be epo:hasConcumptionQuantity and epo:hasSavingsQuantity.
-
The guides/gde_004_eed.pdf · main · eProcurement Group / eForms Group / Docs · GitLab Guide was consulted.
-
At the level of epo:EnergyEfficiencyInformation we will have epo:EnergyEfficiencyItem.
-
Working Group Meeting
Date: 23/01/2025
Participants: Peter Borresen, Paul Donohoe, Yves Jordan
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
eFulfilment meeting regarding Receipt Advice.
-
Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]
-
Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529
-
Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681
Discussions
During the first part of the WGM, eFulfilment and specifically Receipt Advice was discussed: Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.
Regarding the “Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]” github issue:
-
Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.
-
OPP-080-Tender: Kilometers Public Transport: Represented as a predicate to the epo:Quantity class.
-
OPP-035-Tender: Revenues Allocation of tickets sales code uses the following codelist With only one value.
-
OPP-032-Tender: Revenues Allocation: Add epo:hasTicketsSalesRevenueAllocation xsd:decimal, [0..1] attribute on epo:TenderAwardOutcomeInformation.
-
OPP-030-Tender: Contract conditions Code: uses the following codelist.
-
OPP-031-Tender: Contract Conditions Description (other than revenue allocation): epo:hasContractConditionsDescription rdf:plainLiteral. [0..1] attribute on epo:ContractConditio.n
-
OPP-033-Tender: Penalties and Rewards Code: has only one value (found here). Not going to implement.
-
OPP-034-Tender: Penalties and Rewards Description: epo:hasPenaltiesAndRewardsDescription rdf:plainLiteral [0..1] attribute to to epo:TenderAwardOutcomeInformation.
-
-
BT-127-Notice:No modification will happen for now.
Action Points
-
Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.
Working Group Meeting
Date: 21/01/2025
Participants: Paul Donohoe, Yves Jordan, Dragos Stoica
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
Discussions
Regarding Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726:
Regarding OPT-070-Lot:
-
An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest.
-
The latest Notice-types.json eforms document was consulted.
-
Class epo-not:PINTransportationNotice was created as seen on the diagram below.
-
Class epo-not:CANTransportationNotice was created as seen on the diagram below.
-
It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.
Regarding OPT-071-Lot :
-
The Customer-service codelist was found and does not currently exist in ePO and will be added.
-
It was mentioned that For T02 and T01, epo:LotGroup is Forbidden
-
Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.
-
at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.
-
Attribute epo:hasQualityTargetDescription was created.
Regarding Assets in a Contract: (they are all for T02):
-
OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.
-
OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.
-
OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future
-
OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future
Contract terms and other information of a Tender: These are all T02 Notices. It was decided that the WGM will work on the above fields next WGM on 23/01/2025.
OPP-040-Procedure: Main Nature - Sub Type: at-voc:transport-service was created.
Action Points
-
EPO team to look at the F_CEI_EN_DRAFT_2019-03-25.pdf
-
Document and Investigate actual T01,T02 and CEI Notices to confirm that the new ePO diagrams including attribute types are correct.
-
To discuss the removal of epo-not:CallForExpressionOfInterest Class on 28/01/2025 WGM.
Working Group Meeting
Date: 16/01/2025
Participants: Peter Borresen, Paul Donohoe, Yves Jordan, Natalie Muric, Dragos Stoica,
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
-
Alignment with PEPPOL for eFulfilment #569.
-
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
-
Potential problem with modelling of epo:Period #529
-
Mapping of at-voc:timeperiod to the OWL Time Ontology #681
Discussions
Regarding the alignment with PEPPOL for eFulfilment #569, it was decided that the alignment between PEPPOL business term requirements and ePO eFulfilment module will continue with the Receipt Advice Data model.
Regarding the new BTs described in Regulation 2023/2884 to ePO concepts.https://github.com/OP-TED/ePO/issues/691[#691:]
-
BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.
-
BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]
-
BT-682 should be implemented as the foreign Subsidy Measure Conclusion vocabulary connected to Class epo:TenderAwardOutcome as a codelist, using the predicate epo:specifiesForeignSubsidiesMeasureConclusion.
-
A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads
-
BT-684: It was decided that this BT will not be implemented for now.
-
BT-681 : Should points to epo:LotAwardOutcome. .
-
BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)
-
BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.
-
BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.
-
BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.
-
The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.
The epo:InternationalProcurementInstrumentMeasuresInformation Class
-
It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.
Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
-
Lot tenderingTerms Fields were discussed:
-
OPT-070-Lot : Class epo:CallForExpressionOfInterest is a typeOf epo:Notice.
-
Working Group Meeting
Date: 14/01/2025
Participants: Paul Donohoe, Yves Jordan, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Discussions
Regarding #726
-
The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:
-
OPT-111
-
OPT-112
-
OPT-113
-
-
The following Classes were implemented: (also depicted on the diagram below) For the following fields:
-
OPT-110-Lot-FiscalLegis
-
OPT-110-Part-FiscalLegis
-
OPT-120-Lot-FiscalLegis
-
OPT-120-Part-FiscalLegis
-
OPT-130-Lot-FiscalLegis
-
OPT-130-Part-FiscalLegis
-
epo:LegislativeDocumentation
-
epo:FiscalLegalDocumentation
-
epo:EnvironmentalLegalDocumentation
-
epo:EmploymentLegalDocumentation
-
epo:Class epo:Documentation was created that is a generalisation of the above Documentation classes.
-
Predicate providesDocumentation was added fromTaxInformationProvider to epo:Documentation
-
-
-
ΒG-700 was mapped to epo:QualificationCriterion.
-
ΒT-806: The codelist used is in eForms (exclusion-grounds-source) and it has 3 values: epo-notice, epo-sub-espd (this might be epo-acc-espd) and epo-procurement-document. We will create 3 attributes at the level of epo:QualificationCriteria for each value:
-
epo:hasQualificationCriteriaStatedinNotice
-
epo:hasQualificationCriteriaStatedinESPDRequest
-
epo:hasQualificationCriteriaStatedinProcurementDocuments.
-
-
BT-821: uses the same codelist as BT-806.
-
BT-67(a), BT-77(b): epo:hasExclusionGroundType predicate connected to at-voc:exclusion-ground was added.
-
BT-748 At-voc:usage will not be used anymore. Instead we create predicates epo:doesNotRequireSelectionCriterionType epo:hasUnknownUsageOfSelectionCriterionType connected to at-voc:selection-criterion codelist. that will be used in case a specific selection criterion is not used or is not yet known.
-